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Abstract 

The  interactions  of  real-time  tasks  with  each  other  and  with  the  environment  can  be  specified 
in  a  platform-independent  machine  language  called  E  code.  E  code  is  time  safe  if  it  can  be 
scheduled  on  a  given  platform  so  that  all  its  timing  constraints  are  met.  For  specifying  static, 
dynamic,  and  conditional  schedules,  we  propose  again  an  executable  machine  language,  called 
S  code.  A  compiler  for  real-time  programs,  then,  consists  of  a  platform-independent  and  a 
platform-dependent  part.  The  former  produces  E  code;  the  latter  generates  S  code  that  ensures 
the  time-safe  execution  of  the  E  code.  The  run-time  system  consists  of  an  implementation  of 
the  E  machine,  which  interprets  E  code  that  manages  interrupts  from  the  environment,  and  of 
the  S  machine,  which  interprets  S  code  that  manages  task  execution  on  the  processors. 

Generating  nonpreemptive  schedules  for  periodic  tasks  is  NP-hard.  However,  for  E  code 
that  specifies  periodic  tasks,  and  S  code  that  specifies  a  corresponding  nonpreemptive  schedule, 
we  show  that  time  safety  can  be  checked  in  linear  time.  This  suggests  the  notion  of  schedule¬ 
carrying  code  (see),  where  E  code  is  annotated  with  S  code  before  being  sent  to  an  execution 
host.  The  host,  if  it  does  not  trust  the  sender,  can  then  check  the  time  safety  of  the  code  at  a 
cost  that  is  far  below  the  cost  of  generating  a  feasible  schedule. 


1  Introduction 

Schedule-carrying  code  (SCO)  is  real-time  code  annotated  with  the  description  of  a  schedule  that 
witnesses  the  schedulability  of  the  real-time  code.  Schedulability  of  a  real-time  program  is  the 
existence  of  a  scheduler  that  guarantees  the  time  safety  of  all  executions  of  the  program.  Intuitively, 
the  execution  of  a  real-time  program  is  time-safe  if  all  time-critical  components  of  the  program 
execute  according  to  their  timing  constraints.  The  schedule  in  SCO  is  a  witness  of  time  safety. 
We  will  argue  that,  while  generating  SCO  from  real-time  code  may  be  difficult  for  non-trivial 
scheduling  strategies  such  as  non-preemptive  or  multiprocessor  scheduling,  checking  time  safety  of 
see  can  be  easy.  As  a  consequence,  See  can  be  generated  at  compile-time  when  speed  is  not 
of  primary  concern  while  the  validity  of  the  result  can  later  be  verified  at  runtime  prior  to  the 
program  execution  in  order  to  obtain  more  confidence  in  the  temporal  correctness  of  the  code. 

We  propose  the  following  format  for  SCO:  (1)  the  real-time  code  portion  of  SCO  is  E  eode  of  the 
Embedded  Maehine  [2]  and  (2)  the  schedule  portion  of  SCO  is  S  eode  of  the  Seheduling  Maehine, 
which  we  will  introduce  here.  E  code  is  timing  eode  that  determines  the  invocation  of  (software) 
tasks  with  respect  to  the  occurrences  of  events  such  as  clock  ticks.  A  task  is  a  sequential  program, 
e.g.,  a  C  procedure,  without  any  internal  synchronization  mechanisms.  A  task  is  preemptable  but 

*This  research  was  supported  in  part  by  the  DARPA  SEC  grant  F33615-C-98-3614,  the  AFOSR  MURI  grant 
F49620-00-1-0327,  the  California  MICRO  grant  01-037,  and  the  NSF  grants  CCR-0208875  and  CCR-0225610. 
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has  its  own  memory  space.  Tasks  always  operate  on  mutually  disjoint  data.  E  code  invokes  drivers 
to  transport  data  among  tasks  as  well  as  from  tasks  to  the  environment  of  the  system.  Similar  to 
a  task,  a  driver  is  a  sequential  program  but,  unlike  a  task,  is  not  preemptable  and  may  operate 
on  any  memory.  Intuitively,  the  execution  of  E  code  is  time-safe  if  a  driver  that  shares  data  with 
a  task  is  never  invoked  when  that  task  has  already  been  invoked  but  not  yet  completed.  S  code 
is  scheduling  code  that  determines  the  order  in  which  multiple  tasks  invoked  by  the  Embedded 
Machine  execute.  The  purpose  of  S  code  is  to  guarantee  the  time-safe  execution  of  E  code. 

In  Section  2,  we  describe  the  Embedded  Machine  and  define  the  semantics  of  E  code.  The 
Scheduling  Machine  and  the  semantics  of  S  code  is  introduced  in  Section  3.  The  semantics  of 
Schedule-Carrying  Code  is  defined  in  Section  4.  In  Section  5,  we  show  that  the  schedulability 
problem  for  E  code  that  describes  an  arbitrary  set  of  priodic  tasks  is  NP-hard  when  using  a  non- 
preemptive  scheduling  strategy.  Then  we  show  that  the  schedulability  of  SCC  generated  from  a 
successful  non-preemptive  schedulability  test  of  that  E  code  can  be  checked  in  linear  time  in  the 
size  of  the  E  code. 

2  The  Embedded  Machine 

The  E  machine  [2]  is  a  virtual  machine  that  mediates  between  the  physical  processes  and  the 
software  processes  of  an  embedded  system  through  a  control  program  written  in  E  code.  E  code 
triggers  the  execution  of  software  processes  in  relation  to  physical  events,  such  as  clock  ticks,  and 
software  events,  such  as  task  completion.  E  code  is  interpreted  on  the  E  machine  in  real  time.  In 
this  paper,  we  restrict  our  attention  to  the  input-triggered  programs  of  [2] ;  they  are  time-live,  that 
is,  all  synchronous  computation  is  guaranteed  to  terminate. 

E  Code  Syntax.  The  E  machine  supervises  the  execution  of  tasks  and  drivers  that  communicate 
via  ports.  A  task  is  application-level  code  that  implements  a  computation  activity.  A  driver  is 
system-level  code  that  facilitates  a  communication  activity.  A  port  is  a  typed  variable.  Given  a  set 
P  of  ports,  a  P  state  is  a  function  that  maps  each  port  p  G  P  to  a  value  of  the  appropriate  type. 
The  set  P  is  partitioned  into  three  disjoint  sets:  a  set  Pe  of  environment  ports,  a  set  Pt  of  task 
ports,  and  a  set  Pe  of  driver  ports,  updated  respectively  by  the  physical  environment,  by  tasks, 
and  by  drivers.  The  environment  ports  include  pc,  a  discrete  clock.  An  input  event  is  a  change  of 
value  at  an  environment  or  task  port,  say,  at  a  sensor  pg.  A  change  of  value  of  the  discrete  clock  is 
also  called  a  clock  tick.  We  also  say  that  a  change  of  values  at  environment  (task)  ports  constitutes 
an  environment  {software)  event.  An  input  event  is  observed  by  the  E  machine  through  an  event 
interrupt  that  can  be  characterized  by  a  predicate,  namely,  p'g  /  ps,  where  p'g  refers  to  the  current 
port  reading,  and  ps  refers  to  the  most  recent  previous  port  reading.  Pq  C  Pe  U  Pt  denotes  the 
environment  and  task  ports  that  are  observed  by  event  interrupts.  We  call  the  ports  in  Pq  trigger 
ports. 

All  information  between  the  environment  and  the  tasks  flows  through  drivers:  environment 
ports  cannot  be  read  by  tasks,  and  task  ports  cannot  be  read  by  the  environment.  Eormally,  a 
driver  d  consists  of  a  set  P[d\  P  Pd  of  driver  ports,  a  set  /[d]  C  Pe  U  Pt  of  read  environment  and 
task  ports,  and  a  function  f[d]  from  P[d]  U  I[d]  states  to  P[d]  states.  A  task  t  consists  of  a  set 
P[t]  P  Pt  of  task  ports,  a  set  I[f\  P  Pd  of  read  driver  ports,  and  a  function  f[f\  from  P[f\  U  /[t] 
states  to  P[t]  states.  The  E  machine  handles  event  interrupts  through  triggers.  A  trigger  g  consists 
of  a  set  P[g]  P  Pq  of  monitored  environment  and  task  ports,  and  a  predicate  f[g],  which  evaluates 
to  true  or  false  over  each  pair  (s,  s')  of  P[g]  states.  We  require  that  f[g]  evaluates  to  false  if  s  =  s' . 
The  state  s  is  the  state  of  the  ports  at  the  time  instant  when  the  trigger  is  activated.  The  state  s' 
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is  the  state  of  the  ports  at  the  time  instant  when  the  trigger  is  evaluated.  All  active  triggers  are 
logically  evaluated  with  each  event  interrupt.  An  active  trigger  that  evaluates  to  true  is  enabled, 
and  may  cause  the  E  machine  to  execute  E  code.  The  trigger  is  a  time  trigger  if  P[g]  =  {pc}  and 
f[g]  has  the  form  Pc  =  Pc  +  d,  for  some  positive  integer  6  G  N>o.  A  time  trigger  monitors  only  the 
clock  and  specifies  an  enabling  time  6,  which  is  the  number  of  clock  ticks  after  activation  before 
the  trigger  is  enabled. 

The  E  machine  has  three  non-control-flow  instructions.  An  E  instruetion  is  either  call((i),  for 
a  driver  d]  or  schedule(t),  for  a  task  t;  or  future(g', a),  for  a  trigger  g  and  an  E  code  address  a. 
The  ca.ll{d)  instruction  invokes  the  driver  d.  The  schedule(t)  instruction  schedules  the  task  t 
by  handing  t  off  to  a  task  seheduler  that  dispatches  the  scheduled  tasks  to  execute  in  some  order 
after  the  E  machine  is  finished.  The  task  scheduler  could  be  the  scheduler  of  an  operating  system. 
The  future (51,  a)  instruction  marks  the  E  code  at  address  a  for  possible  execution  at  a  future  time 
when  the  trigger  g  becomes  enabled.  The  E  machine  also  has  two  eontrol-flow  instruetions:  the 
conditional  jump  instruction  if  (/,  a),  where  /  is  a  predicate  over  the  driver  ports  Pd,  and  a  is  the 
target  address  of  the  jump  if  /  is  true;  and  the  termination  instruction  return,  which  ends  the 
execution  of  E  code.  Formally,  an  E  program  consists  of  a  set  P  of  ports,  a  set  D  of  drivers,  a  set  T 
of  tasks,  a  set  G  of  triggers,  a  set  A  of  E  code  addresses,  an  initial  E  code  address  oq  G  A,  and  for 
each  E  code  address  a  G  A,  an  E  or  control-flow  instruction  Instruetion  {a) ,  and  a  successor  address 
Next  {a).  All  sets  that  are  part  of  an  E  program  are  finite.  We  require  that  E  code  execution 
always  terminates,  i.e.,  for  each  E  code  address  a  G  A  and  all  branches  of  if  instructions,  a  return 
instruction  must  be  reached  in  a  finite  number  of  steps.  The  E  program  is  time-triggered  if  all 
triggers  g  £  G  are  time  triggers. 

E  Code  Example.  We  illustrate  the  semantics  of  E  code  using  a  simple  program  with  two  tasks, 
ti  and  t2.  The  task  t2  is  executed  every  10  ms;  it  reads  sensor  values  using  a  driver  ds,  processes 
them,  and  writes  its  result  to  an  interconnect  driver  di.  The  task  ti  is  executed  every  20  ms;  it 
obtains  values  from  driver  di  (the  result  of  ^2),  computes  actuator  values,  and  writes  to  an  actuator 
driver  da-  There  are  two  environment  ports  (the  discrete  clock  pc  and  a  sensor  ps),  two  task  ports 
(for  the  results  of  the  two  tasks),  and  three  driver  ports  (the  destinations  of  the  drivers).  The 
following  time-triggered  E  program  implements  the  above  behavior: 

oq:  call((ia)  ai:  call(ds) 

call((i5)  schedule(t2) 

call((ij)  future(p(,  =  Pc  +  10,  ag) 

schedule(ti)  return 

schedule(t2) 

f  uture(p(,  =  Pc  +  10,  ai) 

return 

There  are  two  blocks  of  E  code;  the  block  at  ag  is  executed  initially.  The  E  machine  processes  each 
instruction  in  logical  zero  time.  First,  it  calls  the  driver  da  and  waits  until  the  execution  of  da  is 
finished  (in  logical  zero  time),  and  then  proceeds  immediately  to  the  next  instruction.  Once  dg  and 
di  have  been  called,  all  driver  ports  are  updated.  Then  the  E  machine  schedules  the  task  ti  by 
adding  a  task  invoeation  N  of  the  form  ((ti,  a[ti],  0),  _L)  to  the  so-called  task  set,  which  is  initially 
empty.  a[ti]  denotes  the  initial  program  eounter  of  ti.  0  is  the  amount  of  soft  time  for  which  ti 
already  executed.  The  _L  element  is  not  important  here  and  will  be  explained  later.  As  we  assume 
no  particular  scheduling  scheme,  we  do  not  know  the  organization  of  the  task  set.  If  we  were  to 
use  the  scheduler  of  an  operating  system  the  task  set  could  be  represented  by  the  ready  queue  of 
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the  operating  system.  After  inserting  ti  into  the  task  set,  the  E  machine  immediately  processes  the 
next  instruction  and  adds  t2  to  the  task  set.  Next,  it  proceeds  to  the  future  instruction,  which 
creates  a  trigger  binding  B  of  the  form  =  Pc  +  10,ai,s),  where  s  is  the  current  value  of  pc, 
and  appends  it  to  a  queue,  called  trigger  queue,  of  active  trigger  bindings  (initially  empty).  The 
trigger  queue  ensures  that  the  E  machine  will  execute  the  E  code  block  at  a i  as  soon  as  the  trigger 
=  pc  + 10  is  enabled.  Eor  now  the  E  machine  proceeds  to  the  return  instruction.  Since  no  active 
triggers  are  enabled,  the  E  machine  relinquishes  control  to  the  task  scheduler,  which  takes  over  to 
schedule  the  tasks  ti  and  t2  in  the  task  set.  The  E  machine  wakes  up  again  when  an  input  event 
occurs  that  enables  an  active  trigger.  In  particular,  at  10  ms  the  trigger  binding  (p(,  =  pc  +  10,  oi,  s) 
is  removed  from  the  trigger  queue,  and  the  E  code  at  address  oi  is  executed.  The  execution  of 
block  oi  is  similar  to  that  of  block  oq.  The  whole  process  repeats  every  20  ms. 

The  above  scenario  assumes  that  the  execution  of  a  task  has  completed  before  it  is  scheduled 
again,  in  other  words,  we  need  that  wcet{ti)  +  2  •  wcet{t2)  <  20,  where  wcet{t)  is  the  WCET  of 
task  t.  This  requirement  must  be  checked  by  the  compiler  [3]. 


loop 

invoke  task  dispatcher  (Algorithm  2) 
invoke  E  code  interpreter  (Algorithm  3) 
invoke  task  scheduler  (Algorithm  4) 

end  loop 

Algorithm  1:  The  Embedded  Machine 


E  Code  Semantics.  The  execution  of  an  E  program  yields  an  infinite  sequence  of  program 
conhgurations,  called  traee.  Each  conhguration  tracks  the  values  of  all  ports,  the  trigger  queue,  the 
task  set,  and  the  running  task.  An  E  program  eonfiguration  consists  of  (1)  a  P  state  s',  called  port 
state;  (2)  a  queue  of  trigger  bindings  {g,a,s),  called  trigger  queue,  where  (/  is  a  trigger,  a  G  A  is 
an  E  code  address,  and  s  is  a  P[g\  state;  (3)  a  set  of  task  invoeations  {{t,  at,  (5),  -L),  called  task  set, 
where  t  is  a  task,  at  is  the  program  counter  of  t,  and  6  is  the  amount  of  soft  time  for  which  t  already 
executed  (we  call  {t,at,S)  a  task  instanee  of  t);  and  (4)  a  running  task  R,  where  R  is  either  _L,  or 
else  of  the  form  {N,  _L)  where  N  is  either  _L  or  a  task  instance.  A  trigger  binding  {g,  a,  s)  is  enabled 
if  the  trigger  predicate  p[g\  evaluates  to  true  over  the  pair  (s,  s')  of  P[g\  states.  The  configuration  c 
is  sehedule-enabled  if  the  running  task  of  c  is  _L;  otherwise,  c  is  sehedule-disabled.  c  is  input- enabling 
if  c  is  schedule-disabled  and  the  trigger  queue  contains  no  enabled  trigger  bindings;  otherwise,  c  is 
input- disabling.  We  call  an  input-enabling  c  idling  if  the  running  task  of  c  is  of  the  form  (_L,  •). 

We  define  the  semantics  of  E  code  operationally  using  a  pseudo-code  description  of  the  E  ma¬ 
chine.  Algorithm  1  shows  the  main  loop  of  the  machine  as  it  executes  a  given  E  program.  After 
entering  the  main  loop,  the  machine  invokes  the  task  dispateher  (Algorithm  2)  to  dispatch  the  task 
that  has  been  chosen  by  the  task  scheduler  to  execute.  Since  no  task  is  chosen  initially,  the  task 
dispatcher  enables  the  event  interrupts  and  then  waits  for  environment  events.  The  occurrence  of 
an  environment  event  wakes  up  the  machine,  which  immediately  disables  all  event  interrupts  (thus 
it  is  still  possible  for  low-level  interrupts  to  preempt  the  machine,  as  long  as  they  do  not  interfere 
with  the  triggering  mechanism  of  the  machine).  Then  the  E  machine  interpreter  (Algorithm  3)  is 
invoked. 

The  E  machine  interpreter  runs  through  the  outer  while  loop  of  Algorithm  3  as  long  as  there  are 
enabled  trigger  bindings  in  the  trigger  queue,  each  time  executing  a  block  of  E  code  that  is  bound  to 
an  enabled  trigger.  Initially,  the  trigger  queue  contains  a  single  trigger  binding  (true,  ao,^)  where 
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ao  is  the  initial  E  code  address  of  the  E  program,  and  the  task  set  is  empty.  In  the  inner  while 
loop  of  Algorithm  3,  the  machine  fetches  the  current  instruction  from  the  program,  decodes  and 
executes  the  instruction,  and  then  determines  the  address  of  the  next  instruction. 

After  the  interpreter  is  finished  executing  E  code,  the  task  scheduler  (Algorithm  4)  is  invoked 
to  choose  a  task  from  the  so-called  ready  set  to  execute.  Here  the  ready  set  is  always  equivalent 
to  the  task  set.  The  task  scheduler  Sehedule{ReadySet)  is  free  to  choose  any  scheduling  scheme 
including  an  idling  scheme  where  no  task  is  chosen  although  the  task  set  is  not  empty.  The  chosen 
task  becomes  the  running  task,  which  is  dispatched  by  the  task  dispatcher  to  execute  until  an  input 
event  occurs.  Then  the  task  is  put  back  into  the  task  set  with  its  new  program  counter  only  when 
the  task  has  not  yet  completed.  However,  if  the  task  scheduler  chooses  to  idle  a  running  task  of 
the  form  (T,  •)  is  returned  and  no  task  is  dispatched. 


if  RunningTask  =  (T,  •)  then 
enable  event  interrupts 
(d,  T)  :=  WaitForEnvironmentEventsQ 
disable  event  interrupts 
if  T  =  PortState{PE  \Pc)  then 
PortState{pc)  ■=  PortState{pc)  -|-  S 
/ /  Configuration:  Idle  Time  Tick 
else 

PortState{PE  \Pc)  ■=  T 
/ /  Configuration:  Environment  Event 

end  if 
else 

{{t,at,S),  B)  :=  RunningTask 
enable  event  interrupts 

(a(,  5' ,  PortState{P[t]))  :=  Dispateh{t,  at,  PortState{P[t]  U  I[t])) 
disable  event  interrupts 
PortState{pc)  :=  PortState{pc)  +  d' 
if  a(  =  T  then 

if  H  =  {g,as,s)  then 

TaskSet  :=  TaskSet  U  {(T,  {true,  Ug,  s))} 
end  if 

/ /  Configuration:  Task  Completion 
else 

TaskSet  :=  TaskSet  U  {{{t,a't,5  +  S'),B)} 

/ /  Configuration:  Task  Preemption 

end  if 
end  if 

Algorithm  2:  The  Task  Dispatcher 

An  initial  eonfiguration  of  an  E  program  H  consists  of  (1)  a  P  state;  (2)  the  trigger  queue 
containing  a  single  trigger  binding  {true,  ao,^)  where  qq  is  the  initial  E  code  address  of  H;  (3)  an 
empty  task  set;  and  (4)  the  running  task  set  to  (T,  T).  A  traee  of  H  is  a  finite  or  infinite  sequence 
of  program  configurations  such  that  (1)  the  first  configuration  is  initial  and  (2)  for  any  two  adjacent 
configurations  c  and  P,  one  of  the  following  holds: 

{Environment  Event)  c  is  input-enabling  and  idling,  and  c'  differs  from  c  at  most  in  the  values  of 
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while  there  is  an  enabled  trigger  in  TriggerQueue  do 

{g,ae,s)  :=  GetFirstEnabledTriggerBinding{TriggerQueue) 
TriggerQueue  :=  RemoveFirstEnabledTriggerBinding{TriggerQueue) 
ProgramCounter  :=  Og 
while  ProgramCounter  ^  _L  do 
i  :=  Instruetion{ProgramCounter) 
if  call(d)  =  i  then 

P ortState{P[d])  :=  f[d]{PortState{P[d\  Ul[d])) 
else  if  schedule(t)  =  i  then 

TaskSet  :=  TaskSet  U  {((t,  a[t],  0),  _L)} 
else  if  f  uture(5r,  a)  =  i  then 

TriggerQueue  :=  TriggerQueue  o  {g,a,PortState{P[g\)) 
end  if 

ProgramCounter  :=  Next  {ProgramCounter) 
end  while 
end  while 
Running  Task  :=  _L 
/ /  Configuration:  E  Code  Execution 

Algorithm  3:  The  E  Code  Interpreter 


ReadySet  :=  TaskSet  n  {{N,  -B)|V  task  instances  A  A  V  trigger  bindings  B  with  i?  /  T} 
if  ReadySet  =  0  then 
ReadySet  :=  TaskSet 

end  if 

RunningTask  :=  Sehedule{ReadySet) 
if  RunningTask  /  (T,  •)  then 

TaskSet  :=  TaskSet  \  {RunningTask} 

end  if 

/ /  Configuration:  Task  Scheduling 

Algorithm  4:  The  Task  Scheduler 
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environment  ports  other  than  pc-  In  this  case,  we  write  e-step{c,  c'). 

{Idle  Time  Tiek)  c  is  input-enabling  and  idling,  and  c'  results  from  c  by  incrementing  the  clock  pc- 
In  this  case,  we  write  t-step{c,  0,  c'). 

{Task  Completion)  c  is  input-enabling  and  a  running  task  of  the  form  {{t,  at,  5),  -L)  is  scheduled  in 
c,  and  d  results  from  c  by  incrementing  the  clock  pc  by  some  amount  of  time  5' .  In  addition, 
the  execution  of  t  results  in  the  program  counter  _L  (task  completion)  and  in  a  new  P\t\  state 
of  c' .  In  this  case,  we  write  t-step{c,t,c'). 

{Task  Preemption)  c  is  input-enabling  and  a  running  task  of  the  form  {{t,  at,  5),  -L)  is  scheduled  in 
c,  and  c'  results  from  c  by  incrementing  the  clock  pc  by  some  amount  of  time  5' .  In  addition, 
the  execution  of  t  results  in  a  new  program  counter  a[  of  t  that  is  different  from  _L  and  in  a 
new  P[t]  state  of  d,  and  the  task  set  of  d  results  from  c  by  adding  {{t,  a't,  5  -|-  <5'),  _L)  to  the 
task  set.  In  this  case,  we  write  t-step{c,t,d). 

{E  eode  Exeeution)  c  is  input-disabling  and  schedule-disabled,  and  d  results  from  invoking  the 
E  machine  interpreter  (Algorithm  3)  on  c. 

{Task  Seheduling)  c  is  schedule-enabled,  and  d  results  from  invoking  the  task  scheduler  (Algo¬ 
rithm  4)  on  c. 

A  traee  with  atomie  task  exeeution  of  11  is  a  sequence  of  configurations  such  that  (1)  the  first 
configuration  is  initial  and  (2)  for  any  two  adjacent  configurations  c  and  d ,  either  {Environment 
Event)]  or  {Idle  Time  Tiek)]  or  {Task  Completion)]  or  {E  eode  Exeeution)]  or  {Task  Seheduling) .  In 
a  trace  with  atomic  task  execution,  all  tasks  are  executed  in  zero  time  without  any  task  preemption. 

An  E  program  executes  as  intended  only  if  the  platform  offers  sufficient  performance  so  that 
the  computation  of  a  task  t  always  finishes  before  drivers  access  task  ports  of  t,  and  before  another 
invocation  of  t  is  scheduled.  A  trace  that  satisfies  these  conditions  is  called  time  safe,  because  the 
outcomes  of  if  instructions  cannot  be  distinguished  from  a  trace  with  atomic  task  execution.  Eor- 
mally,  a  configuration  c  time  safe  [2]  if,  for  every  task  t  in  the  task  set  of  c  and  for  every  instruction 
Instruetion{a)  that  is  executed  at  c,  the  following  two  conditions  are  obeyed:  if  Instruetion{a)  = 
call(d),  then  P[d]  Pi  I[t]  =  0  and  I[d]  H  P[t]  =  0;  and  if  Instruetion{a)  =  schedule(t'),  then 
P[t']  n  P[t]  =  0.  If  one  of  these  two  conditions  is  violated,  then  we  say  that  the  configuration  c 
eonfliets  with  the  task  t.  A  trace  is  time  safe  if  it  contains  only  time-safe  configurations. 

Given  a  nonempty  finite  trace  r,  let  last{T)  be  the  final  configuration  of  r.  A  seheduling  strategy 
is  a  function  that  maps  every  nonempty  finite  trace  r  whose  final  configuration  last{T)  is  input¬ 
enabling,  either  to  0  (meaning  that  no  task  is  scheduled),  or  to  some  ready  task  t  G  Tig^^tp)-  An 
infinite  trace  r  =  coCiC2  ...  is  an  outeome  of  the  scheduling  strategy  a  if  for  all  nonempty  finite 
prefixes  r'  =  cq  . . .  Cj  of  r,  if  cj  is  input-enabling,  then  either  e-step{cj,Cj+i)  or  t-step{cj ,  a{d) ,  cj+i) . 
The  E  program  11  is  sehedulable  for  the  WCET  map  wcet  if  there  exists  a  scheduling  strategy  a 
such  that  all  infinite  traces  of  (11,  wcet)  that  are  outcomes  of  a  are  time  safe.  The  sehedulability 
problem  for  E  code  asks,  given  an  E  program  11  and  a  WCET  map  wcet  for  11,  if  11  is  sehedulable 
for  wcet. 

3  The  Scheduling  Machine 

The  Seheduling  Maehine  (S  machine)  is  a  virtual  machine  that  schedules  software  processes  to 
execute  according  to  an  S  eode  program.  S  code  consists  of  instructions  to  execute  a  task  (or  to 
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idle)  until  a  physical  event,  such  as  a  clock  tick,  or  a  software  event,  such  as  the  task  completion, 
occurs. 

S  Code  Syntax.  The  S  machine  schedules  the  execution  of  tasks.  The  S  machine  has  five  non¬ 
control-flow  instructions.  An  S  instruction  is  either  call(d),  for  a  driver  d]  or  schedule (t),  for 
a  task  t]  or  dispatch(t, 51),  for  a  task  t  and  a  trigger  g;  or  idle(gr),  for  a  trigger  g;  or  fork(a) 
for  an  S  code  address  a.  The  call  and  schedule  instructions  are  equivalent  to  the  corresponding 
E  instructions  of  the  E  machine.  The  dispatch(t,  51)  instruction  dispatches  the  task  t  to  execute 
until  either  t  completes  or  the  trigger  g  is  enabled,  whatever  comes  first.  The  S  machine  yields 
to  t  after  executing  the  dispatch(t,  51)  instruction.  The  idle(gf)  instruction  idles  the  S  machine 
until  the  trigger  g  is  enabled.  The  f  ork(a)  instruction  marks  the  S  code  at  address  a  for  execution 
in  parallel  to  the  current  control  flow.  The  S  machine  has  only  a  single  control-flow  instruction: 
the  termination  instruction  return,  which  ends  the  execution  of  S  code.  The  S  machine  may  have 
other  control-flow  instructions  such  as  a  conditional  jump  instruction  in  order  to  describe  dynamic 
scheduling  schemes.  Without  any  additional  control-flow  instructions  we  call  S  code  static  since  it 
can  only  describe  static  schedules.  In  this  paper,  we  focus  on  static  S  code.  Eormally,  an  S  program 
consists  of  a  set  P  of  ports,  a  set  D  of  drivers,  a  set  T  of  tasks,  a  set  G  of  triggers,  a  set  A  of  S  code 
addresses,  an  initial  S  code  address  oq  G  A,  and  for  each  S  code  address  a  G  A,  an  S  or  control-flow 
instruction  Instruction  (a) ,  and  a  successor  address  Next{a).  All  sets  that  are  part  of  an  S  program 
are  finite.  We  require  that  S  code  execution  always  eventually  yields  or  terminates,  i.e.,  for  each 
S  code  address  a  G  A,  either  a  dispatch  or  an  idle  instruction,  or  else  a  return  instruction  must 
be  reached  in  a  finite  number  of  steps.  The  S  program  is  time-triggered  if  all  triggers  g  G  G  are  time 
triggers  and  if  all  instructions  that  immediately  precede  a  fork  instruction  are  idle  instructions. 

S  Code  Example.  We  illustrate  the  semantics  of  S  code  using  the  program  of  Section  2  with 
the  two  tasks  ti  and  t2-  Recall  that  the  task  t2  is  executed  every  10  ms  whereas  the  task  ti  is 
executed  every  20  ms.  The  following  time-triggered  S  program  implements  this  behavior,  which  is 
equivalent  to  the  behavior  of  the  E  program  in  Section  2: 

qq:  call(da) 
call(ds) 
call(di) 
schedule(ti) 
schedule(t2) 
dispatch(t2) 
oi:  dispatch(ti) 

idle(pc  =Pc  +  10) 

02:  call(ds) 

schedule(t2) 

dispatch(t2) 

idle(pc  =  Pc  +  20) 
f ork(ao) 
return 

There  is  one  block  of  S  code  with  the  initial  S  code  address  oq.  We  also  call  a  block  of  S  code  a 
thread.  The  S  machine  processes  each  instruction  in  logical  zero  time.  The  first  five  instructions  are 
executed  in  the  same  way  the  E  machine  executes  them.  Then,  the  S  machine  proceeds  to  the  first 


dispatch(t2)  instruction,  which  replaces  the  task  invocation  ((t2,  a[t2],  0),  _L)  created  by  the  preced¬ 
ing  schedule(t2)  instruction  by  a  so-called  thread  instance  of  the  form  {{t2,a[t2\,0),  {false,  ai,  s)), 
where  s  is  the  value  of  pc  when  the  S  machine  began  executing  at  oq.  Note  that  a  dispatch(t) 
instruction  is  an  abbreviation  for  dispatch(t,/afee).  The  new  thread  instance  of  ai  ensures  that 
the  S  machine  will  execute  the  S  code  block  at  oi  as  soon  as  task  t2  completes.  For  now  the 
S  machine  yields  to  t2-  When  t2  completes,  the  S  machine  wakes  up,  removes  the  thread  instance 
from  the  task  set,  and  then  executes  the  dispatch(ti)  instruction  at  oi  in  a  similar  way.  After 
ti  completes,  the  S  machine  proceeds  to  the  idle(p'^  =  Pc  +  10)  instruction,  which  creates  in  the 
task  set  a  thread  instance  of  the  form  (T,  (p'^  =  Pc  +  10, 02,5)),  which  we  also  call  an  idle  phase, 
where  s  is  again  the  value  of  pc  when  the  S  machine  began  executing  at  oq.  Now,  the  S  machine 
idles  until  the  trigger  Pc  =  Pc  +  10  is  enabled  at  10  ms.  Then  the  idle  phase  is  removed  from  the 
task  set  and  the  S  code  at  address  02  is  executed  in  a  similar  way  than  the  previous  S  code.  At 
20  ms,  the  S  machine  executes  the  fork(ao)  instruction,  which  creates  in  the  task  set  a  (zero)  idle 
phase  of  the  form  (T,  {true,ao,  s')),  where  s'  is  the  current  port  state  of  all  trigger  ports  Pq  of  the 
S  program.  Thus  the  f  ork(ao)  instruction  starts  a  new  instance  of  the  thread  at  oq.  The  following 
return  instruction  terminates  the  current  thread.  Then  the  S  machine  immediately  removes  the 
(zero)  idle  phase  from  the  task  set  and  starts  executing  the  S  code  at  oq.  The  whole  process  repeats 
every  20  ms. 

The  above  scenario  assumes  that  the  execution  of  both  tasks  completes  within  10  ms.  In  other 
words,  we  need  that  wcet{ti)  +wcet{t2)  <  10,  where  wcet{t)  is  the  WCET  of  task  t.  We  call  S  code 
in  which  task  execution  must  neither  be  preempted  by  S  code  nor  other  tasks  synchronous.  The 
following  time-triggered  S  program  implements  again  the  above  behavior  where,  however,  task  ti 
may  be  preempted  by  S  code  and  by  task  t2. 

oq:  call((ia) 
call((i5) 
ca.ll{di) 
schedule(ti) 
schedule(t2) 
dispatch(t2) 

oi:  dispatch(ti,p(,  =  Pc+  10) 

02:  idle(p(,  =  Pc -h  10) 
ca.ll{ds) 

schedule(t2) 
dispatch(t2) 
dispatch(ti) 
idle(p(,  =Pc  +  20) 
f ork(ao) 
return 

The  dispatch  instruction  at  address  ai  creates  a  thread  instance  of  the  form  ((fi,  a[ti]),  (pc  =  Pc  + 
10, 02,  s)),  where  s  is  again  the  value  of  pc  when  the  S  machine  began  executing  at  oq.  If  ti  completes 
before  10  ms  elapsed  the  S  machine  will  proceed  to  the  subsequent  idle  instruction  and  idle  until 
the  10  ms  elapsed.  Technically,  when  ti  completes,  the  task  dispatcher  replaces  the  above  thread 
instance  in  the  task  set  by  an  enabled  thread  instance  of  the  form  {{ti,  T),  {true,  02,  s)),  which  makes 
the  S  machine  immediately  proceed  to  the  idle  instruction  at  02-  On  the  other  hand,  if  ti  does  not 
complete  before  10  ms  elapsed  ti  gets  preempted  by  the  S  machine.  Then  the  above  thread  instance 
is  removed  from  the  task  set  and  the  idle  instruction  at  02  is  executed.  Since  10  ms  already  elapsed 
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the  idle  instruction  creates  an  already  enabled  thread  instance,  which  makes  the  S  machine  proceed 
immediately  to  the  following  call  instruction.  Thus  the  subsequent  dispatch(t2)  instruction  may 
execute  task  t2  before  task  ti  completed.  Then  the  following  dispatch(ti)  instruction  executes  ti 
or,  if  ti  has  already  completed,  proceeds  immediately  to  the  idle  instruction  to  wait  for  the  next 
20  ms  instant. 

The  above  scenario  assumes  that  the  execution  of  a  task  has  completed  before  it  is  scheduled 
again  but  not  necessarily  before  other  tasks  are  dispatched.  In  other  words,  we  need  that  wcet{ti)  + 
2  •  wcet{t2)  <  20,  where  wcet{t)  is  the  WCET  of  task  t.  We  call  S  code  in  which  task  execution 
may  be  preempted  by  S  code  and  other  tasks  preemptive.  The  following  time-triggered  S  program 
implements  again  the  above  behavior  where,  however,  task  ti  may  be  preempted  by  S  code  but  not 
by  task  t2. 

oq:  call(da) 
call((i5) 
ca.ll{di) 
schedule(ti) 
schedule(t2) 
dispatch(t2) 

oi:  dispatch(ti,p'^  =  Pc+  10) 

02:  idle(pc  =  Pc  +  10) 

call((i5) 
schedule(t2) 
dispatch(ti) 
dispatch(t2) 

idle(pc  =  Pc  +  20) 
f ork(ao) 
return 

The  only  difference  of  this  S  code  block  to  the  previous  block  is  the  order  of  the  last  two  dispatch 
instructions.  Instead  of  dispatching  t2  even  before  ti  may  have  completed,  ti  is  dispatched  again 
at  the  10  ms  instant.  Then,  after  ti  completes,  t2  is  dispatched.  Thus  we  assume  again  that 
the  execution  of  a  task  has  completed  before  it  is  scheduled  again  but  in  addition  we  assume 
that  each  task  completes  before  another  task  is  dispatched.  In  other  words,  we  again  need  that 
wcet{ti)  +  2  •  wcet{t2)  <  20,  where  wcet{t)  is  the  WCET  of  task  t,  and  that  tasks  do  not  preempt 
each  other.  We  call  S  code  in  which  task  execution  may  be  preempted  by  S  code  but  not  by  other 
tasks  non-preemptive. 

S  Code  Semantics.  The  execution  of  an  S  program  yields  an  infinite  sequence  of  program 
configurations,  called  traee.  Each  configuration  tracks  the  values  of  all  ports,  the  task  set,  and 
the  running  task.  An  S  program  eonfiguration  consists  of  (1)  a  P  state  s',  called  port  state;  (2)  a 
set  of  task  invocations  and  thread  instanees  {N,  {g,a,s)),  called  task  set,  where  N  is  either  a  task 
instance  or  T  and  (p,  a,  s)  is  a  trigger  binding  in  which  p  is  a  trigger,  a  G  A  is  an  S  code  address, 
and  s  is  a  Pq  state  (if  A"  is  T  we  call  the  thread  instance  an  idle  phase);  and  (3)  a  running  task  R, 
where  R  is  either  T,  or  else  of  the  form  (A,  T)  where  A  is  either  T  or  a  task  instance.  A  thread 
instance  (A,  (p,a,s))  is  enabled  if  the  trigger  predicate  p[g\  evaluates  to  true  over  the  pair  (s,s') 
of  P[g\  states.  The  configuration  c  is  sehedule- enabled  if  the  running  task  of  c  is  T;  otherwise,  c  is 
sehedule- disabled,  c  is  input- enabling  if  c  is  schedule-disabled  and  the  task  set  contains  no  enabled 
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thread  instances;  otherwise,  c  is  input- disabling.  We  call  an  input-enabling  c  idling  if  the  running 
task  of  c  is  of  the  form  (-L,  •). 

We  define  the  semantics  of  S  code  operationally  using  a  pseudo-code  description  of  the  S  ma¬ 
chine.  Algorithm  5  shows  the  main  loop  of  the  machine  as  it  executes  a  given  S  program.  Al¬ 
gorithm  5  is  similar  to  Algorithm  1.  Instead  of  using  the  E  machine  interpreter  we  now  use  the 
S  machine  interpreter  (Algorithm  6).  The  task  dispatcher  and  task  scheduler  can  be  reused  from 
the  E  machine.  Similar  to  the  E  machine,  after  entering  the  main  loop,  the  S  machine  invokes 
the  task  dispatcher  to  dispatch  the  task  that  has  been  chosen  by  the  task  scheduler  to  execute. 
Since  no  task  is  chosen  initially,  the  task  dispatcher  enables  the  event  interrupts  and  then  waits 
for  environment  events.  The  occurrence  of  an  environment  event  wakes  up  the  machine,  which 
immediately  disables  all  event  interrupts.  Then  the  S  machine  interpreter  is  invoked. 

The  S  machine  interpreter  runs  through  the  outer  while  loop  of  Algorithm  6  as  long  as  there 
are  enabled  thread  instances  in  the  task  set,  each  time  executing  a  thread  of  S  code  that  is 
bound  to  an  enabled  thread  instance.  Initially,  the  task  set  contains  a  single  thread  instance 
(T,  {true,  qq,  P ortState{PG)))  where  ao  is  the  initial  S  code  address  of  the  S  program.  In  the  inner 
while  loop  of  Algorithm  6,  the  machine  fetches  the  current  instruction  from  the  program,  decodes 
and  executes  the  instruction,  and  then  determines  the  address  of  the  next  instruction. 

Similar  to  the  E  machine,  after  the  interpreter  is  finished  executing  S  code,  the  task  scheduler 
is  invoked  to  choose  a  task  from  the  ready  set  to  execute.  Unlike  in  the  E  machine,  the  ready 
set  contains  only  the  thread  instances  of  the  task  set,  unless  there  are  no  thread  instances  in  the 
task  set.  In  this  case,  the  ready  set  is  equivalent  to  the  task  set.  This  gives  priority  to  thread 
instances  over  task  invocations.  As  before,  the  task  scheduler  Schedule{ReadySet)  is  free  to  choose 
any  scheduling  scheme  including  an  idling  scheme  where  no  task  is  chosen  although  the  task  set  is 
not  empty.  The  chosen  task  becomes  the  running  task,  which  is  dispatched  by  the  task  dispatcher 
to  execute  until  an  input  event  occurs.  Then  the  task  is  put  back  into  the  task  set  with  its  new 
program  counter  only  when  the  task  has  not  yet  completed.  If  the  task  has  completed  and  it  was 
part  of  a  thread  instance,  an  enabled  idle  phase  is  inserted  into  the  task  set  to  make  the  S  machine 
continue  the  thread.  However,  if  the  task  scheduler  chooses  to  idle  a  running  task  of  the  form  (T,  •) 
is  returned  and  no  task  is  dispatched. 


loop 

invoke  task  dispatcher  (Algorithm  2) 
invoke  S  code  interpreter  (Algorithm  6) 
invoke  task  scheduler  (Algorithm  4) 

end  loop 

Algorithm  5:  The  Scheduling  Machine 

An  initial  configuration  of  an  S  program  H  consists  of  (1)  a  P  state;  (2)  the  task  set  containing 
a  single  thread  instance  (T,  {true,  oq,  PortState{PG)))  where  ao  is  the  initial  S  code  address  of  H; 
and  (3)  the  running  task  set  to  (T,  T).  A  trace  of  H  is  a  finite  or  infinite  sequence  of  program  con¬ 
figurations  such  that  (1)  the  first  configuration  is  initial  and  (2)  for  any  two  adjacent  configurations 
c  and  c',  one  of  the  following  holds: 

{Environment  Event)  c  is  input-enabling  and  idling,  and  c'  differs  from  c  at  most  in  the  values  of 
environment  ports  other  than  pc.  In  this  case,  we  write  e-step{c,  c'). 

{Idle  Time  Tick)  c  is  input-enabling  and  idling,  and  c'  results  from  c  by  incrementing  the  clock  pc- 
In  this  case,  we  write  t-step{c,  0,  c'). 
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while  there  is  an  enabled  thread  in  TaskSet  do 

{N,  {g,  Us,  s))  :=  ChooseEnabledThreadInstance{TaskSet) 

TaskSet  :=  TaskSet  \  {N,  {g,  ag,  s)) 
if  /  _L  then 

TaskSet  :=  TaskSet  U  {{N,  _L)} 
end  if 

ProgramCounter  :=  a^;  Yield  :=  false 
while  ProgramCounter  7^  _L  do 
i  :=  Instruetion{ProgramCounter) 

if  call(d)  =  i  then 

PortState{P[d])  :=  f[d]{PortState{P[d]  U/[d])) 
else  if  schedule(t)  =  i  then 

TaskSet  :=  TaskSet  C  {((t,  a[t],  0),  _L)} 
else  if  dispatch(t,  O')  =  i  then 

if  there  is  a  task  invocation  ((t,at,5),  _L)  in  TaskSet  then 

TaskSet  :=  {TaskSet  \{{{t,  at,  5),  Y)})  U  {{{t,at,5),{g,Next{ProgramCounter),s))} 
Yield  :=  true 
end  if 

else  if  idle(5r)  =  i  then 

TaskSet  :=  TaskSet  U  {(_L,  {g,  Next{ProgramCounter),  s))} 

Yield  :=  true 
else  if  fork(a)  =  i  then 

TaskSet  :=  TaskSet  U  {(_L,  {true,  a,  PortState{PG)))} 

end  if 

if  Yield  then 

ProgramCounter  :=  _L 
else 

ProgramCounter  :=  Next{ProgramCounter) 

end  if 
end  while 
end  while 

Running  Task  :=  _L 
/ /  Configuration:  S  Code  Execution 

Algorithm  6:  The  S  Code  Interpreter 
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(Task  Completion)  c  is  input-enabling  and  a  running  task  of  the  form  ((t,  at,  5),  B)  is  scheduled  in 
c,  and  c'  results  from  c  by  incrementing  the  clock  pc  by  some  amount  of  time  5' .  In  addition, 
the  execution  of  t  results  in  the  program  counter  _L  (task  completion)  and  in  a  new  P[t] 
state  of  c',  and,  if  i?  is  a  trigger  binding  (g,  a^,  s),  the  task  set  of  c'  results  from  c  by  adding 
{J-,  {true,  Os,  s))  to  the  task  set.  In  this  case,  we  write  t-step{c,t,c'). 

{Task  Preemption)  c  is  input-enabling  and  a  running  task  of  the  form  {{t,  at,  d),  B)  is  scheduled  in 
c,  and  d  results  from  c  by  incrementing  the  clock  pc  by  some  amount  of  time  b' .  In  addition, 
the  execution  of  t  results  in  a  new  program  counter  a)  of  t  that  is  different  from  _L  and  in  a 
new  P[t]  state  of  d,  and  the  task  set  of  d  results  from  c  by  adding  {{t,  a[,  6  +  5'),  B)  to  the 
task  set.  In  this  case,  we  write  t-step{c,t,d). 

{S  eode  Exeeution)  c  is  input-disabling  and  schedule-disabled,  and  d  results  from  invoking  the 
S  machine  interpreter  (Algorithm  6)  on  c. 

{Task  Seheduling)  c  is  schedule-enabled,  and  d  results  from  invoking  the  task  scheduler  (Algo¬ 
rithm  4)  on  c. 


4  Schedule-Carrying  Code 

In  this  section,  we  introduce  the  notion  of  schedule-carrying  code.  In  general,  the  time-safe  execu¬ 
tion  of  an  E  program  requires  a  system  scheduler  to  determine  the  order  in  which  tasks  triggered 
by  the  E  program  are  executed.  However,  a  system  scheduler  can  also  be  replaced  or  at  least  sim¬ 
plified  when  using  the  S  machine.  S  code  determines  the  order  in  which  tasks  execute.  Eor  a  given 
E  program  and  given  platform  constraints  (e.g.,  WCETs),  S  code  may  be  generated  according  to 
any  scheduling  strategy  at  compile  time  (static  scheduling),  at  runtime  (dynamic  scheduling),  or 
even  partially  at  compile  time  and  completed  at  runtime.  S  code  may  then  serve  as  (1)  a  witness  of 
time-safety  of  a  given  E  program  and  (2)  an  executable  representation  of  a  schedule.  If  the  S  code 
dispatches  at  most  a  single  task  at  any  moment  in  time,  a  system  scheduler  will  not  be  necessary 
anymore.  Thus  the  S  machine  is  a  possible  alternative  to  a  system  scheduler.  We  argue  that  gener¬ 
ating  S  code  is  difficult  in  the  presence  of  non-trivial  platform  constraints  such  as  nonpreemptable 
tasks  while  checking  time  safety  of  E  code  annotated  with  S  code  is  simple.  We  therefore  call  an 
E  program  annotated  with  an  S  program  sehedule-earrying  eode  (SCO). 

see  Example.  We  illustrate  the  semantics  of  SCO  by  combining  the  E  program  of  Section  2 
with  a  version  of  the  non-preemptive  S  program  of  Section  3  that  does  not  contain  any  of  the  call 
and  schedule  instructions.  The  following  time-triggered  SCO  program  implements  the  triggering 
behavior  of  the  E  program  and  the  non-preemptive  scheduling  behavior  of  the  S  program: 


call(da) 

ai:  call((i<j)  Ogi 

dispatch(t2) 

call(ds) 

schedule(t2) 

dispatch(ti,p(,  =  Pc  +  10) 

call(dj) 

f  uture(p(,  =  Pc  +  10,  ao) 

idle(p(,  =  Pc  +  10) 

schedule(ti) 

return  a[ : 

dispatch(ti) 

schedule(t2) 

dispatch(t2) 

future(p(,  =  Pc  +  10,  ai) 

idle(p(,  =  Pc  +  20) 

return 

f ork(aQ) 
return 
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The  two  E  code  blocks  at  oq  and  ai  are  equivalent  to  the  E  code  blocks  in  Section  2.  The  E  code 
address  oq  is  the  initial  E  code  address  of  the  SCO  program.  In  addition,  there  is  one  block  of  S  code 
at  Oq,  which  is  the  initial  S  code  address  of  the  SCO  program.  The  execution  of  the  SCO  program 
starts  with  the  E  code  block  at  oq.  When  the  E  machine  is  finished  executing  this  block,  the 
S  machine  starts  executing  the  S  code  block  at  Oq.  After  dispatching  task  t2  and  then  ti,  the 
S  machine  gets  preempted  by  the  E  machine  at  the  10  ms  instant.  Then  the  E  machine  executes 
the  E  code  block  at  ai.  Subsequently,  the  S  machine  continues  to  execute  the  S  code  at  a'l-  At 
the  20  ms  instant,  the  E  machine  wakes  up  and  starts  a  new  round  by  executing  the  E  code  block 
at  oq. 


see  Semantics.  An  SCC  program  consists  of  an  E  program  and  an  S  program  that  may  share 
ports,  drivers,  tasks,  and  triggers.  An  SCC  program  is  time-triggered  if  the  E  program  and  the 
S  program  are  time-triggered.  The  execution  of  an  SCC  program  yields  an  infinite  sequence  of 
program  configurations,  called  traee.  Each  configuration  tracks  the  values  of  all  ports,  the  trigger 
queue,  the  task  set,  and  the  running  task.  An  SCC  program  eonfiguration  consists  of  (1)  a  P 
state  s',  called  port  state;  (2)  a  queue  of  trigger  bindings  {g,a,s),  called  trigger  queue,  where  g 
is  a  trigger,  a  G  A  is  an  E  code  address,  and  s  is  a  P[g\  state;  (3)  a  set  of  task  invocations  and 
thread  instanees  {N,{g,a,s)),  called  task  set,  where  N  is  either  a  task  instance  or  _L  and  {g,a,s) 
is  a  trigger  binding  in  which  gf  is  a  trigger,  a  G  A  is  an  S  code  address,  and  s  is  a  Pq  state  (if  N 
is  _L  we  call  the  thread  instance  an  idle  phase);  and  (4)  a  running  task  R,  where  R  is  either  _L, 
or  else  of  the  form  {N,  _L)  where  N  is  either  _L  or  a  task  instance.  A  thread  instance  {N,  {g,  a,  s)) 
is  enabled  if  the  trigger  predicate  p[g\  evaluates  to  true  over  the  pair  (s,  s')  of  P[g]  states.  The 
configuration  c  is  sehedule-enabled  if  the  running  task  of  c  is  _L;  otherwise,  c  is  sehedule- disabled,  c 
is  input- enabling  if  c  is  schedule-disabled,  the  trigger  queue  contains  no  enabled  trigger  bindings, 
and  the  task  set  contains  no  enabled  thread  instances;  otherwise,  c  is  input- disabling.  We  call  an 
input-enabling  c  idling  if  the  running  task  of  c  is  of  the  form  (_L,  •). 

We  define  the  semantics  of  SCC  code  operationally  using  a  pseudo-code  description  of  the 
SCC  machine.  Algorithm  7  shows  the  main  loop  of  the  machine  as  it  executes  a  given  SCC  pro¬ 
gram.  Similar  to  the  E  and  S  machines,  after  entering  the  main  loop,  the  SCC  machine  invokes 
the  task  dispatcher  to  dispatch  the  task  that  has  been  chosen  by  the  task  scheduler  to  execute. 
Since  no  task  is  chosen  initially,  the  task  dispatcher  enables  the  event  interrupts  and  then  waits 
for  environment  events.  The  occurrence  of  an  environment  event  wakes  up  the  machine,  which 
immediately  disables  all  event  interrupts.  Then  the  E  machine  interpreter  is  invoked  followed  by 
the  S  machine  interpreter.  Einally,  the  task  scheduler  chooses  a  task  to  execute. 


loop 

invoke  task  dispatcher  (Algorithm  2) 
invoke  E  code  interpreter  (Algorithm  3) 
invoke  S  code  interpreter  (Algorithm  6) 
invoke  task  scheduler  (Algorithm  4) 

end  loop 

Algorithm  7:  The  SCC  Machine 

An  initial  eonfiguration  of  an  SCC  program  11  consists  of  (1)  a  P  state;  (2)  the  trigger  queue 
containing  a  single  trigger  binding  {true,ao,^)  where  uq  is  the  initial  E  code  address  of  H;  (3)  the 
task  set  containing  a  single  thread  instance  {J-,{true,aQ,  PortState{PG)))  where  o'q  is  the  initial 
S  code  address  of  H;  and  (4)  the  running  task  set  to  (_L,  _L).  A  traee  of  11  is  a  finite  or  infinite 
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sequence  of  program  configurations  such  that  (1)  the  first  configuration  is  initial  and  (2)  for  any 

two  adjacent  configurations  c  and  c' ,  one  of  the  following  holds: 

{Environment  Event)  c  is  input-enabling  and  idling,  and  c'  differs  from  c  at  most  in  the  values  of 
environment  ports  other  than  pc-  In  this  case,  we  write  e-step{c,  c'). 

{Idle  Time  Tiek)  c  is  input-enabling  and  idling,  and  c'  results  from  c  by  incrementing  the  clock  p^- 
In  this  case,  we  write  t-step{c,  0,  c'). 

{Task  Completion)  c  is  input-enabling  and  a  running  task  of  the  form  {{t,  at,  5),  B)  is  scheduled  in 
c,  and  c'  results  from  c  by  incrementing  the  clock  pc  by  some  amount  of  time  S'.  In  addition, 
the  execution  of  t  results  in  the  program  counter  _L  (task  completion)  and  in  a  new  P[t] 
state  of  c' ,  and,  if  i?  is  a  trigger  binding  {g,  as,  s),  the  task  set  of  c'  results  from  c  by  adding 
{T,  {true,  as,  s))  to  the  task  set.  In  this  case,  we  write  t-step{c,t,c'). 

{Task  Preemption)  c  is  input-enabling  and  a  running  task  of  the  form  {{t,  at,  S),  B)  is  scheduled  in 
c,  and  c'  results  from  c  by  incrementing  the  clock  pc  by  some  amount  of  time  S'.  In  addition, 
the  execution  of  t  results  in  a  new  program  counter  a(  of  t  that  is  different  from  _L  and  in  a 
new  P[t]  state  of  c',  and  the  task  set  of  c'  results  from  c  by  adding  {{t,  a't,  S  +  S'),  B)  to  the 
task  set.  In  this  case,  we  write  t-step{c,t,c'). 

{E  eode  Exeeution)  c  is  input-disabling  and  schedule-disabled,  there  are  enabled  trigger  bindings 
in  c,  and  c'  results  from  invoking  the  E  machine  interpreter  (Algorithm  3)  on  c. 

(5  eode  Exeeution)  c  is  input-disabling  and  schedule-disabled,  there  are  no  enabled  trigger  bindings 
but  enabled  thread  instances  in  c,  and  c'  results  from  invoking  the  S  machine  interpreter 
(Algorithm  6)  on  c. 

{Task  Seheduling)  c  is  schedule-enabled,  and  c'  results  from  invoking  the  task  scheduler  (Algo¬ 
rithm  4)  on  c. 


5  Non-Preemptive  Scheduling  for  E  Code 

In  this  section  we  discuss  a  potential  application  of  the  SCO  on  a  real  time  system  for  which  the 
execution  of  a  requested  task  not  only  must  be  completed  before  its  deadline,  but  is  also  required 
not  to  be  preempted.  Non-preemptive  scheduling  may  be  preferred  solution  for  addressing  the 
problem  of  shared  resources  and  critical  sections,  it  reduces  task  switching  overhead  and  for  some 
applications  task  preemption  is  even  not  allowed.  Unfortunately,  it  is  well  known  that  generating 
non-preemptive  code  is  computationally  hard  even  for  uniprocessor  scheduling  and  is  usually  treated 
by  branch- and-bound  algorithms  with  exponential  complexity  in  the  worst  case.  Only  recently,  the 
researchers  have  shown  that  problem  remains  NP-hard  even  for  some  simple  classes  of  task  sets. 
The  problem  of  testing  the  feasibility  of  a  set  of  periodic  tasks  with  arbitrary  arrival  times  was 
shown  to  be  NP-hard  in  the  strong  sense  in  [4].  The  hardness  result  for  the  case  where  all  tasks 
have  the  same  arrival  time  was  presented  in  [1].  Even  the  case  when  a  period  vr*  of  each  task 
ti  from  a  task  set  is  characterised  by  a  relation  vTj  =  2'^7ro,  where  j  is  an  integer  and  tto  is  the 
smallest  period  in  the  task  set,  turned  out  to  be  NP-hard  in  the  strong  sense  [5].  In  this  section 
we  argue  that  once  the  schedule  has  been  generated  and  represented  by  S  code  part  of  the  SCO  it 
can  be  efficiently  checked  for  deadline  and  non- preemption  requirements.  At  the  end  we  show  that 
similar  proposition  holds  if  input  task  set  is  specified  in  the  high  level  language  such  as  Giotto.  We 
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start  with  some  basic  scheduling  terminology  and  with  the  hardness  result  for  a  non-preemptive 
scheduling  problem  that  motivates  this  section. 

Non-preemptive  Scheduling  Problem.  A  periodic  task  t  is  given  with  a  3-tuple  t  =  (a,  tt,  wcet), 
where  a  is  the  arrival  time  of  t,  tt  is  the  period  of  t  and  wcet  is  the  worst  case  execution  time  of 
t.  The  arrival  time  of  the  j-th  request  for  processing  of  the  task  t  is  a  +  (j  —  l)7r,  and  its  deadline 
is  a  +  j-TT.  Given  a  set  of  periodic  tasks  Tasks  to  be  executed  on  a  single  processor,  a  schedule  is 
a  function  that  maps  processing  time  units  to  requests  of  the  tasks  in  Tasks.  For  non-preemptive 
scheduling,  a  schedule  is  valid  if  processing  of  each  request  of  each  task  from  Tasks: 

1.  starts  on  or  after  the  request  arrival, 

2.  is  not  preempted  for  the  task  worst  case  execution  time,  and 

3.  terminates  on  or  before  the  request  deadline. 

The  task  set  Tasks  is  said  to  be  feasible  if  there  exists  a  valid  schedule  for  it. 

Cai  and  Kong  [1]  have  shown  the  following  scheduling  problem  to  be  NP-hard  in  the  strong 
sense. 

NSPT  Problem  Non-preemptive  scheduling  of  a  simply  periodic  task  set. 

Instance  A  set  of  non-preemptible  periodic  tasks  Tasks  =  {ti,  ^2,  •••,  tn}  to  be  executed  on  a  single 
processor.  The  arrival  of  each  task  ti  is  zero,  i.e.  ti  =  (0,  TTj,  rccetj).  The  periods  of  the 
tasks  satisfy  relation  tti+i  =  KjTTj  for  1  <  i  <  n  —  1  {simply  periodic  task  set).  The  numbers 
TTi,wceti  (1  <  i  <  n),  and  AT,  (1  <i<n  —  l)  are  assumed  to  be  positive  integers. 

Question  Is  the  task  set  Tasks  feasible? 

It  is  clear  that  the  same  hardness  result  holds  if  we  keep  task  arrival  times  at  zero,  but  allow 
arbitrary  task  periods.  In  the  next  subsection  we  define  a  subclass  of  time-triggered  E  programs, 
the  class  of  periodic  E  programs  V  such  that  each  E  program  G  P  describes  requests  of  an 
instance  of  a  such  periodic  task  set.  Eor  the  purposes  of  this  section  we  define  the  class  with 
respect  to  the  set  of  E  program  addresses,  and  Instruction  and  Next  function  part  of  an  E  program 
definition.  Given  a  periodic  E  program  11®  G  "P  we  next  define  a  subclass  5(11®)  of  time-triggered 
S  programs,  the  class  of  S  programs  SCO  compliant  with  H®.  Such  a  class  of  programs  describes 
all,  for  the  purposes  of  this  paper,  interesting  schedules  of  the  Tasks  set,  while  keeping  the  size  of 
each  program  in  it  bounded  with  the  size  of  11®. 

Non-preemptive  Scheduling  for  E  Code.  Let  for  a  set  of  periodic  tasks  Tasks  =  {ti,t2,  ■■■Nn} 
the  arrival  of  each  task  ti  be  zero,  i.e.  ti  =  {0,TTi,wceti).  This  assumption  allows  analysis  to  be 
performed  up  to  tt  =  lcm(7ri,  7r2, ...,  vr^)  time  units,  where  1cm  stands  for  the  least  common  multiple 
function.  If  7  =  lcd(7ri,7r2,  ■..,TTn)  is  the  least  common  divisor  of  the  task  periods  and  if  A:  =  vr/y, 
each  request  for  a  task  execution  in  the  interval  [0,  tt)  is  issued  at  a  time  instant  jy  for  some  integer 
i)  0  <  j  <  /c  —  1.  An  E  program  H®  G  P  consists  of  /c  E  code  blocks  H®  for  0  <  j  <  A  —  1.  Let,  for 
0  <  j  <  A  —  1,  Tasks j  =  {U  G  Tasks  \  jy  mod  tt*  =  0}  be  the  set  of  all  tasks  reqested  at  time  jj  and 
let  n®  =  I  Tasks  j  \  (0  <  n®  <  n) .  Eor  0  <  j  <  A:  —  1  we  define  a  set  of  addresses  for  E  code  block  11^ 
with  A®  =  {a®  j  I  0  <  i  <  n®  +  1}.  Each  block  11^  is  contained  of  a  sequence  of  nj  schedule,  one 
future  and  one  return  instruction  in  the  specified  order.  The  set  of  addresses  of  the  E  program  11® 
is  given  with  A®  =  IJo<i<fc-i  ^j-  initial  address  of  11®  is  Oq  q.  The  successor  address  function 
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satisfies  Next{aj  j)  =  if  0  <  f  <  n®  +  1  and  Next{aj^^e_^_i)  =  _L.  For  0  <  j  <  k  —  1  the 

instruction  function  Instruction  satisfes  the  following  three  conditions: 

1.  for  each  t  G  Tasks  j  there  is  an  integer  i  such  that  0  <  i  <  and  Instruction{a'jj)  =  schedule(t), 

2.  if  0  <  j  <  /c  —  1  then  Instruction{aj^^e)  =  future(p'^  =  Pc  +  7, 

in  addition  Instruction{a^_-^^  )  =  future(|?^  =  Pc  +  7,  Oq  o)> 

3.  Instruction{a'^ =  return. 

An  S  program  11®  from  5(11®)  consists  of  /c  S  code  blocks  Ilj  for  0  <  j  <  k  —  1.  Each  block 
nj  is  contained  of  a  sequence  of  Uj  dispatch  instructions  that  are  separated  by  at  most  one  idle 
instruction,  and  ends  with  one  idle,  one  fork  and  one  return  instruction  in  the  specified  order. 
A  trigger  g  in  a  schedule  or  idle  instruction  is  a  time  trigger  specified  with  an  integer  A,  i.e.  g 
is  enabled  if  >  pc  +  A.  If  the  size  of  the  S  code  block  H®  is  n®  we  have  that  nj  <  2nj  +  3.  For 
0  <  j  <  A:  —  1  we  define  a  set  of  addresses  for  S  code  block  Ilj  with  =  {a®  j  |  0  <  i  <  nj  —  1}. 
The  set  of  addresses  of  the  S  program  H®  is  given  with  A®  =  Uo<i<fc-i^j-  initial  address 
of  n®  is  Oqq.  The  successor  address  function  satisfies  Aexf(a®  J  =  aj  j+i  if  0  <  i  <  nj  —  1  and 
Aexf(a®  s_i)  =  T.  The  instruction  function  Instruction  satisfes  the  following  five  conditions: 

j 

1.  if  for  some  t  G  Tasks,  some  trigger  0  <  j  <  A:  —  1  and  0  <  i  <  nj  —  3,  Instruction{aj  = 

dispatch(t,  then  for  some  t'  G  Tasks  and  trigger  g' ,  Instruction{a^j  =  dispatch(t',  gr') 
or  Instruction  {a  J  =  idle(5r'), 

2.  if  for  some  trigger  o',  0  <  j  <  A:  —  1  and  0  <  i  <  nj  —  3,  Instruction  {a  j  j)  =  idle(5r)  then  for 

some  t'  G  Tasks  and  trigger  g',  Instruction  {a  j  =  dispatch(t',  ^r'), 

3.  Instruction{aj  =  idle(5r)  for  some  trigger  g, 

4.  if  0  <  j  <  A:  — 1  then  Instruction{aj^^s_2)  =  f  ork(a®_,_i  g);  in  addition  Instruction  {a  ^_2)  = 

fork(ago), 

5.  Instruction{aj  ^s_i)  =  return. 

Lastly,  in  order  for  the  S  program  11®  to  be  SCO  compliant  with  the  E  program  11®,  we  additionally 
require  that  the  numbers  of  dispatch  and  schedule  instructions,  Uj  and  Uj,  and  the  number  of  E 
(and  S)  code  blocks  k  satisfy  the  condition 

+  (1) 

j=0  j=Q 

The  size  of  an  S  program  11®  that  satisfies  the  last  condition  is  linear  in  the  size  of  the  E  program 
n®.  On  the  other  hand,  this  condition  allows  execution  of  tasks  that  are  preempted  by  some  or 
even  all  k  E  code  blocks  11^.  For  the  case  of  non-preemptive  schedules,  no  task  may  be  preempted 
by  any  other  task,  so  no  task  may  be  dispatched  twice  in  the  same  S  code  block.  Therefore,  a 
class  of  S  programs  that  describes  such  schedules  satisfies  the  condition  1.  Checking  if  a  given  E 
program  is  periodic  or  if  a  given  S  program  is  SCC  compliant  with  a  given  E  program  requires  time 
linear  in  the  size  of  the  programs.  Therefore,  in  the  rest  of  this  section  we  assume  that  only  E  and 
S  programs  that  passed  these  tests  may  be  input  programs  of  the  algorithm  that  we  discuss  next. 
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ETime  :=  0;  AETime  :=  0;  Period  :=  0 
RunningTask  :=  (_L,  •);  Preempted  :=  false 
CLe  ■=  o-o.o 

TaskSet  :=  {{A,  {true,  ETime))} 
while  Period  <  2  do 

invoke  task  dispatch  checker  (Algorithm  9) 
invoke  E  code  checker  (Algorithm  10) 
invoke  S  code  checker  (Algorithm  11) 
if  TaskSet  /  0  then 

RunningTask  :=  GetTask{TaskSet) 
else 

RunningTask  :=  (-L,  •) 

end  if 
end  while 
return  ACCEPT 

Algorithm  8:  The  Non-preemptive  SCO  Checker 


The  Algorithm  8  shows  the  main  loop  of  the  procedure  for  checking  validity  and  non-preemption 
of  the  schedule  for  the  schedule-carrying  code  11  consisting  of  a  periodic  E  program  G  V  and 
an  S  program  G  5(11®).  We  assume  that  Oqq  and  Oqq  are  initial  addresses  of  A®  and  A® 
respectively,  and  that  wcet  is  the  worst  case  execution  map.  The  structure  of  the  Algorithm  8 
is  very  similar  to  the  main  loop  of  the  SCC  Machine  Algorithm  7.  It  follows  the  same  steps 
by  simulating  task  dispatching  (Algorithm  9),  E  code  interpretation  (Algorithm  10),  and  S  code 
interpretation  (Algorithm  11).  Since  S  programs  from  5(11®)  describe  only  static  schedules,  i.e. 
at  any  time  there  is  at  most  one  enabled  thread  instance,  invocation  of  the  task  scheduler  from 
the  SCC  machine  algorithm  is  replaced  with  the  simple  GetTask  call.  While  thread  instances  in 
TaskSet  are  manipulated  in  the  same  manner  as  for  the  SCC  machine,  the  trigger  queue  is  not 
used,  since  at  any  time  only  one  trigger  is  activated  due  to  a  single  future  instruction  in  each  E 
code  block.  Instead,  the  algorithm  keeps  the  time  of  the  last  E  machine  interpreter  invocation  in 
the  ETime  variable,  periodically  updating  it  with  AETime  time  units  remembered  from  the  last 
future  instruction.  To  verify  the  schedule  it  is  enough  to  check  its  validity  in  the  interval  [0,  tt], 
including  the  vr  instant  since  all  of  the  periodic  tasks  have  their  deadlines  at  that  time.  At  the  same 
time  E  machine  interpreter  would  again  execute  E  code  at  the  address  OgO’  ^  variable 

Period,  a  counter  variable  for  the  executions  of  the  instruction  at  Oq  g,  as  a  test  for  the  completion 
of  the  check  in  case  of  accepting  the  schedule  as  a  valid  one.  The  variable  STime  keeps  track  of  the 
times  in  which  task  dispatcher  would  have  been  invoked.  To  compute  the  next  dispatching  time 
NextSTime,  the  Algorithm  9  uses  the  current  data  of  the  running  task  t:  the  time  5  for  which  t 
already  executed  from  the  task  instance,  and  the  trigger  g  and  the  time  s  of  the  activation  of  g 
from  the  trigger  binding.  NextSTime  is  determined  by  the  first  event  that  would  have  come:  g 
becomes  enabled  (s  -T  A),  the  execution  of  t  is  completed  {STime  +  wcet{f)  —  (5),  or  E  machine  is 
invoked  {ETime  +  AETime).  In  all  cases  the  new  time  for  which  task  t  would  have  been  executed 
up  to  that  instant  is  updated  in  the  task  instance.  Since  no  task  actually  executes  the  stored  value 
for  the  program  counter  at  is  irrelevant.  The  Algorithm  10  is  executed  if  E  machine  should  have 
been  invoked,  i.e.  when  STime  =  ETime  +  AETime.  When  E  code  interpretation  loop  decodes 
schedule(t)  instruction,  it  checks  whether  an  instance  of  the  same  task  t  is  already  in  the  TaskSet. 
If  it  is,  the  execution  of  t  for  its  previous  request  could  not  have  been  completed,  time  safety  is 
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if  RunningTask  =  {-L,B)  then 
if  -B  =  (p'c  >  pc  +  A,as,  s)  then 

NextSTime  :=  niiii(s  +  A,  ETime  +  AETime) 

/ /  Configuration:  Idle  Time  Tick 
else 

NextSTime  :=  ETime  +  AETime 
/ /  Configuration:  Environment  Event 

end  if 
else 

{{t,at,S),{g,as,s))  :=  RunningTask 
if  Preempted  and  (5  =  0  then 
//  3t'.  (((t',-,(5'),-)  e  TaskSet  A  t'  ^  t  A  S'  >  0) 

/ /  Non-preemption  Violation 
return  REJECT 
end  if 

if  5  =  (pc  >  Pc  +  A)  then 

NextSTime  :=  niin(s  -T  A,  STime  -T  wcet{t)  —  S,  ETime  -T  AETime) 
else 

NextSTime  :=  niin(STzme  -T  wcet{t)  —  S,  ETime  -T  AETime) 

end  if 

if  NextSTime  =  STime  -T  wcet(t)  —  S  then 
TaskSet  :=  TaskSet  U  {(T,  {true,  Ug,  s))} 

Preempted  :=  false 
/ /  Configuration:  Task  Completion 
else 

TaskSet  :=  TaskSet  D  {{{t,  at,  S  +  NextSTime  —  STime),  {g,as,  s))} 
Preempted  :=  true 
/ /  Configuration:  Task  Preemption 

end  if 
end  if 

STime  :=  NextSTime 

Algorithm  9:  The  Task  Dispatch  Checker 
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if  STime  =  ETime  +  AETime  then 
ETime  :=  ETime  +  AETime 
Program  Counter  :=  Oe 
if  ProgramCounter  —  ®o,o  then 
Period  :=  Period  +  1 
end  if 

while  ProgramCounter  ^  _L  do 
i  :=  Instruction{ProgramCounter) 
if  schedule(t)  =  i  then 
if  ((t,  •,  •),  •)  G  TaskSet  then 
return  REJECT 
/ /  Deadline  Violation 
end  if 

TaskSet  :=  TaskSet  C  {((t,  a[t],  0),  J_)} 
else  if  f uture(p^  =  pc  +  A,a)  =  i  then 
AETime  :=  A;  Oe  :=  a 

end  if 

ProgramCounter  :=  Next  {ProgramCounter) 

end  while 
end  if 

Running  Task  :=  J_ 

Algorithm  10:  The  E  Code  Checker 


violated  and  the  algorithm  terminates  by  rejecting  If.  If  it  is  not,  there  is  a  new  request  for  t, 
so  it  is  inserted  in  the  TaskSet  with  zero  time  executed  so  far.  Non-preemption  violation  could 
be  similarly  tested  when  dispatching  a  task  t  in  the  Algorithm  9,  by  checking  if  any  other  in 
TaskSet  already  started  its  execution  {S'  >  0).  However,  in  order  to  make  each  execution  of  the 
Algorithm  9  independant  of  the  number  of  tasks  in  TaskSet,  even  constant  in  time,  we  use  a  boolean 
variable  Preempted  to  keep  track  if  the  task  that  was  last  dispatched  completed  its  execution  or 
was  preempted.  Non-preemption  violation  is  detected  when  a  first  dispatch  of  a  task  invocation 
{S  =  0)  occurs  while  Preempted  is  true.  The  Algorithm  11  is  the  same  as  S  code  interpreter  part  of 
the  see  machine,  except  for  the  control-flow  optimizations  due  to  the  fact  that  at  any  time  there 
is  at  most  one  enabled  thread  instance. 

Proposition  5.1 

Let  a  schedule-carrying  code  H  be  given  with  a  periodic  E  program  H®  G  P  and  an  S  program  SCC 
compliant  with  H®.  Let  the  worst  case  execution  map  for  tasks  in  H  be  wcet.  Checking  if  H  is  time 
safe  for  wcet  map  and  if  no  task  preempts  any  other  task  can  be  done  in  time  linear  in  the  size  of 
the  E  program  H®,  i.e.  in  0(|n®|)  time. 

Proof  het  k  be  the  number  of  E  (and  S)  code  blocks.  The  worst  case  running  time  is  achieved  if  the 
algorithm  accepts  the  schedule  after  the  variable  Period  becomes  2.  Before  that  the  Algorithm  10  is 
executed  exactly  k  +  1  times,  each  time  starting  from  the  address  q,  0  <  j  <  k  +  1.  Therefore, 

each  E  program  instruction  is  decoded  at  most  twice  and  since  processing  of  each  instruction  takes 
constant  time,  the  total  time  spent  in  the  Algorithm  10  is  0(|n®|).  The  while  loop  in  the  Algorithm 
11  runs  until  dispatch{- ,  g)  or  idle{g)  instruction  is  decoded  with  a  trigger  g  not  enabled.  Since 
thread  continuation  is  achieved  through  fork  instruction,  similarly  as  for  an  E  program  instruction. 
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if  there  is  an  enabled  thread  in  TaskSet  then 

{N,{g,as,s))  :=  GetEnabledThreadInstance{TaskSet) 

TaskSet  :=  TaskSet  \  {N,  {g,  a^,  s)) 
if  /  _L  then 

TaskSet  :=  TaskSet  U  {{N,  _L)} 
end  if 

ProgramCounter  :=  a^;  Yield  :=  false 
while  ProgramCounter  7^  _L  do 
Reset  :=  false 

i  :=  Instruetion{ProgramCounter) 
if  dispatch(t,  51)  =  i  then 

if  there  is  a  task  invocation  ((t,at,6),  -L)  in  TaskSet  and  g  is  not  enabled  then 

TaskSet  :=  {TaskSet\{{{t,at,S),±)})  U  {{{t,at,6),{g,Next{ProgramCounter),s))} 
Yield  :=  true 

end  if 

else  if  idle(5r)  =  i  then 
if  g  is  not  enabled  then 

TaskSet  :=  TaskSet  U  {(_L,  {g,  Next  {ProgramCounter),  s))} 

Yield  :=  true 

end  if 

else  if  fork(a)  =  i  then 
s  :=  ETime 
Reset  :=  true 
ProgramCounter  :=  a 

end  if 

if  Yield  then 

ProgramCounter  :=  _L 
else  if  not  Reset  then 

ProgramCounter  :=  Next{ProgramCounter) 

end  if 
end  while 
end  if 

Running  Task  :=  _L 

Algorithm  11:  The  S  Code  Checker 
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we  have  that  each  S  program  instruction  is  decoded  at  most  twice  and  processed  in  constant  time. 
Finally,  the  Algorithm  9  runs  in  constant  time  at  most  once  per  S  program  instruction.  Since  the 
condition  1  requires  the  size  of  S  program  to  be  bounded  by  the  size  of  E  program,  the  whole 
Algorithm  8  runs  in  time  linear  in  the  size  of  the  E  program.  □ 

Non-preemptive  Scheduling  for  Giotto.  We  conclude  the  section  by  showing  that  similar 
complexity  gap  between  generating  and  checking  a  non-preemptive  schedule  exists  if  the  task  set 
description  is  given  in  the  Giotto  programming  language  [3]. 

NSGP  Problem  Non-preemptive  scheduling  of  a  single  mode  Giotto  program. 

Instance  A  Giotto  program  IIg  with  a  single  mode  m.  A  period  of  the  mode  m  is  7r[m]  G  N>o  and 
its  set  of  task  invocations  is  Invokes[m\.  Each  task  t  from  Invokes[m\  is  non-preemptible  and 
given  with  a  pair  of  positive  integers  {ijj{t),wcet{t)),  where  uj{t)  is  the  task  frequency  relative 
to  the  mode  period  and  wcet{t)  is  the  task  worst  case  execution  time. 

Question  Is  the  task  set  in  the  program  nc  feasible? 

Proposition  5.2 

The  NSGP  problem  is  NP-hard  in  the  strong  sense. 

Proof  We  prove  the  proposition  by  a  direct  polynomial-time  transformation  from  the  NSPT  prob¬ 
lem.  Given  an  instance  of  the  NSPT  problem,  a  simply  periodic  task  set  Tasks  =  {ti,t2, 
with  ti  =  (0,  TTj,  rccetj),  we  constuct  a  Giotto  program  with  a  single  mode  m,  such  that  7r[m]  = 
lcni(7ri,  7r2,  ...,vr„)  and  Invokes[m\  =  {{7r[m\ / iTi,  wceti)\ti  G  Tasks}.  The  equivalence  of  feasibility  of 
the  task  sets  in  the  two  problems  follows  from  the  Giotto  program  semantics,  which  implies  task 
arrival  times  at  time  zero,  periodic  task  invocations  and  requires  task  completion  before  the  next 
request  occurs.  □ 

Given  an  instance  of  the  NSGP  problem  and  a  schedule,  we  next  show  how  difficult  is  to  check 
whether  the  schedule  is  a  valid  schedule.  Let  \Invokes[m\  \  =  n  and  for  each  (tOi,  wceti)  G  Invokes[m] 
(1  <  i  <  n)  let  TTj  be  the  period  of  the  task  tj,  tt*  =  7r[m]/a;i.  If  IF  =  maxi<j<„a;i  the  total  number 
of  task  requests  in  a  single  mode  period  7r[m],  bounded  by  nIF.  A  schedule  is 

given  with  a  function  S{i,j)  that  maps  a  j-th  request  (1  <  j  <  uJi)  of  the  task  ti  {1  <  i  <  n) 
to  the  starting  execution  time  of  the  request.  Prom  the  three  conditions  of  the  definition  of  the 
valid  non-preemptive  schedule  it  follows  that  the  function  S  must  satisfy  the  corresponding  three 
conditions: 

1.  (j  —  l)7ri  <  S{i,j)  <  jiTi,  for  each  1  <  i  <  n  and  each  1  <  j  <  Wj, 

2.  S{ii,ji)>S{i2,j2)  5(ii,ji)  >  5(i2,j2)  +  for  each  1  <  ii,  i2  <  n,  each  1  <  ji  <  tJq, 

and  each  1  <  j2  <  Wjj  >  and 

3.  (j  —  l)7ri  <  S{i,j)  +  wceti  <  j^rj,  for  each  1  <  i  <  n  and  each  1  <  j  <  a;*. 

Proposition  5.3 

Given  a  schedule  function  S  for  the  NSGP  problem,  checking  if  the  schedule  is  valid  can  be  done 
in  time  no  more  than  0(nlFlog(nlF)). 

Proof  Since  the  task  execution  times  are  positive  numbers,  for  conditions  1  and  3  we  need  to  check 
if  (j  —  l)7rj  <  S{i,j)  and  S{i,j)  +  wceti  <  for  1  <  i  <  n  and  1  <  j  <  Wi.  This  can  be 
done  in  O(nlF)  time.  To  check  the  non-preemption  condition  2  we  first  sort  all  S{i,j)  values  in 
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0{nWlog{nW))  time  and  then  for  every  two  adjacent  elements  S{ii,ji)  >  S{i2,j2)  of  the  sorted 
list  we  check  if  S{ii,ji)  >  5(^2,  J2)  +  wceti^  {0{nW)  time).  □ 
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